What

nerve config validate checks a whole config bundle and exits non-zero on any error, so it drops straight into CI on a config repo. It covers unknown keys, cron job and gate parsing, source sanity, ${VAR} resolvability, and schedules the scheduler would not actually run as written.

--portable-only drops the machine-local layers and judges the tracked layer alone. --strict-keys and --strict-env promote warnings to errors. It runs even when the config cannot otherwise load, which is the point.

Why

Every class of error here was previously found by a daemon at start-up, after the change had already merged and synced — leaving the instance on its old config with a log line nobody was reading. Moving the check before the merge is the whole value.

Schedules are the clearest case. A 5-field crontab the scheduler rejects (99 * * * *) is refused at run time and logged. A schedule that is neither a crontab nor an interval (hourly, @daily) is never complained about at run time at all — it silently never fires.

--portable-only exists because a machine-local override can mask an invalid shared value, and, more commonly, a broken local file condemns a shared bundle with nothing wrong with it. Validating the tracked layer on its own is the only question whose answer does not depend on which host ran the check.

Validation reads and parses; it does not execute candidate gate-plugin code. "An invalid bundle is refused" is not a guarantee you can make about code you had to run in order to judge it, so an unrecognised gate type is reported as unverified rather than accepted or rejected. Testing a plugin is the author's job.

Added in review

The validator rejected blank path values that the loader accepts. It refused
a blank workspace, cron.jobs_file, cron.system_file or
cron.gate_plugins_dir on the stated premise that Path("") is Path("."), so
a blank "means the directory the daemon happened to be started in". It does not:
_expand_path maps blank to None before it can become Path("."), and the
field takes its documented default. A single validator run showed both halves —
the log line resolving the blank to the default, then the error saying it
resolved to the working directory.

The shape that hits it is jobs_file: ${CRON_JOBS_FILE:-}, and the docs promote
${VAR:-default} as the fleet idiom. docs/config.md carried both readings in
two places, and the suite pinned both contracts with TestBlankPathSettingsMeanUnset
and TestWorkingDirectoryPaths green side by side.

Blank is no longer reported. An explicit . / ./ / ./. stays a hard error,
because those do survive the loader as the path they are.

The rule was also a hand-written four-key literal against fourteen path settings,
so gateway.ssl.cert accepted a dot that switches TLS on with a directory as the
certificate. The keys are now derived from the config dataclasses: one test walks
every Path-annotated field and fails if it is neither covered nor exempted with
a reason, a second fails if the rule names a field the config does not declare,
and a third asserts each covered key actually produces an error — so a key cannot
be listed and never read. Six settings that check turned up are now covered.

🤖 Generated with Claude Code